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(57) Abstract: An implementation of packet data control protocol (PDCP) parameter negotiation in a universal mobile telephone 
communications service (UMTS) which can also be used to improve GSM/GPRS XBD negotiation methods, where the timing for 
exactly when the new parameters are to take effect must be known includes either a GPRS-type reset solution or a PDCP-header 
based change indicator solution. In the GPRS-type reset solution, PDCP negotiations are made and then connections are reset to put 
into effect the new PDCP parameters for use. The second solution is to add a change indicator, e.g., a bit (C-bit) to the PDCP-PDU*s 
header part. The originator informs using this bit that new parameter values are to take effect for use. 
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CHANGING XID/PDCP PARAMETERS DURING CONNECTION 

FIELD OF THE INVENTION 
The invention is related to packet traffic in both 
5 the General Packet Radio Service (GPRS) and the proposed 
Universal Mobile Telecommunications System (UMTS) for 
mobile telecommunication and, more particularly, to 
changing parameters during a connection. 

10 BACKGROUND OF THE INVENTION 

The proposed Universal Mobile Telecommunications 
System (UMTS) of Fig. 1A has a packet data protocol stack 
in the user plane, as shown in Fig. IB that has some 
differences as compared to the prior General Packet Radio 
15 Service (GPRS) of Figs. 2A and 2B, partly due to a new 

radio interface technology and partly due to much higher 
quality of service (QoS) requirements. In both systems, 
there is a need to negotiate certain parameters during 
setup, including compression algorithms. In GPRS the 
20 negotiated parameters are called exchange identification 
(XID) , while in UMTS the negotiated parameters are called 
Packet Data Control Protocol (PDCP) parameters, which are 
more or less the same kind of parameters. 

In the General Packet Radio Service (GPRS) of Fig. 
25 2A, XID parameters are used in the Logical Link Control 
(LLC) and Subnetwork Dependent Convergence Protocol 
(SNDCP) layers of Fig. 2B . These protocols are located 
in the mobile station (MS) and in the Serving GPRS 
Support Node (SGSN) , as shown in Fig. 2B . An example 
3 0 situation where there might be a need for renegotiation 
in GPRS is handover. New network elements don't 
necessarily have the same features as the old one(s), so 
there might be a need to renegotiate XID parameters. 
In the UMTS of Figs. 1A and IB, the Packet Data 
35 Convergence Protocol (PDCP) (the old name shown in Fig. 

IB is L3CE) corresponds to the SNDCP protocol of Fig. 2B. 
(there is no protocol in UMTS that is similar to LLC) . 

1 
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PDCP is located in the MS and the Radio Network 
Controller (RNC) of the Radio Access Network (RAN) of 
Figs. 1A and IB. 

Typical XID/PDCP parameters are header compression 
5 methods, protocol version, etc. The negotiation is 

normally a two-way negotiation. First the initiator (in 
GPRS the initiator can be either the MS or network side 
element) requests . XID/PDCP parameters which are suitable 
for it. Parameters are transferred to the peer entity, 

10 which selects suitable (parameters that it can support) 
XID/PDCP parameters and negotiates values within certain 
rules. Those negotiated XID/PDCP parameters are returned 
back to the initiator. 

The main problem is that both ends have to know 

15 exactly when the new values have taken effect, i.e., when 
to start using the new XID/PDCP parameters. Some 
parameters don f t cause a problem but, e.g., in 
compression algorithms, the receiver must know exactly 
when a new compression algorithm is used. 

2 0 In UMTS as compared to GPRS, there are major 

differences related to handovers and protocol 
architecture. These changes reflect on PDCP negotiation. 

The main requirement still exists in UMTS, i.e., both 
ends have to know exactly when new PDCP parameters are to 
25 take effect for use. Architectural changes are the 

removing of the LLC layer and the new location of PDCP 
(corresponding to SNDCP layer) , which is RNC. 

There is a situation in UMTS called Serving Radio 
Network Subsystem (SRNS) relocation, i.e., inter Radio 

3 0 Network Controller (RNC) handover. Such would be, for 

instance, a change from one of the RNCs shown in Fig. 1A 
to the other. Execution of that handover is not allowed 
to disturb or suspend the user data transmission. The 
factors which ensure the reliability of transmission with 
35 high confidence have to be maximized. There should be 
means to renegotiate the PDCP parameters for such a 
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relocation . 

It would also be advantageous for such means to be 
able to be used any time, not necessarily during a 
handover or relocation, for both . GPRS and UMTS 
5 applications, without requiring any reset type procedure. 

SUMMARY OF INVENTION 
The first solution according to the present 
invention is similar to GPRS. 
10 In GPRS, this is handled by resetting the whole 

connection. So XID negotiation is made firstly and then 
connections are reset (LLC layer connections are re- 
established) . After reset, the new XID parameters are 
taken up for use. Typically in GPRS, renegotiation is 
15 made during handover (inter SGSN handover) . So XID 

negotiation is made during handover procedures, and after 
handover (LLC layer) connections are reset. When the 
handover procedure is finished, data transfer starts with 
renegotiated XID parameters. Data transmission is 
20 suspended the whole time of the handover procedure. 

In UMTS, there, is no LLC layer, but the Radio Link 
Control (RLC) layer can be used instead. By resetting 
RLC connections the same function can be achieved. So, 
according to a first aspect of the invention, PDCP 
25 negotiation is made, and then connections are reset to 

put into effept the new PDCP parameters for use. (Note: 

The RLC layer already has Reset -PDUs (Packet Data 
Units), which can be used to reset RLC links.) If during 
the SRNS relocation procedure the RLC links are reset, 
3 0 the reset can be used also for PDCP negotiation purposes. 

There are dynamically created protocol entities in 
UMTS at the RLC and PDCP layers which have responsibility 
for functions of the layer. The location of these layers 
are in the RNC and in the User Equipment (UE) , such as an 
35 MS. Those layer entities get initial values by help of 
which their actual functionality can be started. In 

3 
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cases where the SRNC is changed and a new SRNC is started 
up, i.e., the RLC and PDCP layers are relocated due to 
handover, it is therefore feasible to reset these 
protocol entities of the layers. This is done instead of 
5 copying the detailed entity information, i.e., state 
machines to the new SRNC. The reason for this is 
reduction of the complexity and to incrementally increase 
reliability. Thus .the only information which is copied 
and has to be transferred between source and target SRNCs 

10 are the data packet buffers of the source SRNC. This 
speeds up the handover process which is an important 
feature especially for RT applications. 

In conclusion, the reset procedure is used in GPRS 
and also in UMTS during handover, according to the first 

15 solution of the invention. However, if negotiation is 
needed to be made during a normal connection (not 
handover), the reset procedure is not very feasible. 
E.g., some packets have to be retransmitted and the reset 
causes some delay. 

2 0 So, if the RLC links are not to be reset, the 

following second solution can be used during normal data 
transmission. The second solution for the problem, 
according to the invention, is to add a change indicator 
such as a bit (C-bit) or equivalent to the PDCP-PDU's 

2 5 header part. The sender informs on this bit that new 

parameter values are to take effect for use. 

It should be noted that the change indicator may be 
used in other applications where there is need to change 
parameters during connection with the following 

3 0 underlying requirements (not necessarily only for 

PDCP/XID negotiation) : 

both ends must know exactly when the new values 
of the parameters are to take effect for use; 
and 

35 - new values cannot be directly derived from the 

packet . 
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The following describes in detail only one potential 
application of this invention. It should be realized 
however that the disclosed change indicator solution is 
applicable to indicate any kind of change in parameters. 
PDCP/XID negotiation is only an example for change 
indicator usage. 

These and other objects, features and advantages of 
the present invention will become more apparent in light 
of the following detailed description of a best mode 
embodiment thereof, as illustrated in the accompanying 
drawing . 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1A shows the proposed UMTS packet network 
architecture . 

Fig. IB shows the proposed UMTS user plane protocol 
stack. 

Fig. 2A shows the GPRS network architecture. 

Fig. 2B shows the GPRS user plane protocol stack. 

Fig. 3 shows a first part of an SRNS handover 
scenario, before the SRNS relocation and location 
registration. 

Fig. 4 shows a second part of the SRNS handover 
scenario after the SRNS relocation and location 
registration. 

Fig. 5 illustrates a signaling sequence chart. 

Fig. 6 shows a PDCP-data-PDU format for the proposed 

UMTS. 

Fig. 7 shows how such a PDU might be changed to 
accommodate the change indicator of the present 
invention. 

Fig. 8 shows a sequence of steps carried out by an 
originator for an unreliable negotiation scenario, 
according to the present invention. 

Fig. 9 shows a sequence of steps carried out by a 
receiver in said unreliable negotiation scenario. 
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according to the present invention. 

Fig. 10 shows a sequence of steps carried out by an 
originator for a reliable negotiation scenario, according 
to the present invention. 

Fig. 11 shows a sequence of steps carried out by a 
receiver in said reliable negotiation scenario, according 
to the present invention. 

Fig. 12 shows a system including both an originator 
and a receiver, according to the second aspect of the 
present invention. 

BEST MODE FOR CARRYING OUT THE INVENTION 

Figs 3 and 4 illustrate a UMTS scenario of Serving 
Radio Network Controller (SRNC) handover, before and 
after the SRNC relocation, respectively. Fig. 5 
illustrates a related a signaling sequence. 

The Serving Radio Network Subsystem (SRNS) 
relocation procedure (see 3 GPP - TS 23.121 chapter 
4.3.12.2) is used to change the RNC control point, i.e., 
inter RNC handover. In this procedure, the location of 
PDCP changes in the network side. Because different RNCs 
may support different XID parameters, XID (re) negotiation 
is usually made during SRNS relocation. 

The Packet Data Control Protocol (PDCP) parameters 
are delivered, for example, as described in the copending 
patent application entitled "Transfer of PDCP Parameters 
During Handover of a Mobile Station Between Radio Network 
Subsystems", filed on November 29, 1999 under U.S. 
Provisional Application Serial No. 60/167,924. 

The reset solution of the present invention will be 
described first. It is the duty of the target SRNC to 
execute all specific PDCP parameter setup procedures, 
i.e., related to the header compression method, as shown 
in Fig. 5 before the SRNC_Relocation_Commit message is 
received from the source SRNC. Right after that a 
Reset_Request is sent to the UE which resets the PDCP 
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entity and optionally the RLC entity of the UE . The RLC 
entity reset is possible but not necessary. RLC reset 
procedure can be potentially used by sending a RESET PDU 
(described in 3G TS 25.322) but this can be implemented 
5 also another way. The most essential part of the PDCP 
reset is reset of the header compressor/decompressor 
after which the first packets are transmitted/received 
with full headers-. -Successful resets are indicated, as 
in Fig. 5, with Reset_Conf irm. In the target SRNC "the 

10 creation of the RLC and PDCP entities corresponds to a 

reset. The creation is executed before the Reset_Request 
is sent to the UE. The relocation is completed after the 
resets and the corresponding primitives a,re conveyed to 
the correct elements. At the same time the data transfer 

15 can be started. It has to be ascertained that the first 
headers are not compressed. This means that the reset 
compressor sends packets with full headers. The exact 
number of uncompressed packets is not tied to a certain 
value but it must be great enough to become convinced 

20 that packets are really getting across to the destination 
and no synchronization loss occurs. When this is clear, 
the header compression can be started. 

It is an objective for the UMTS that it should be 
designed for future demands and be a generic platform for 

25 different kinds of methods. The reset in handover will 
result in such suitable circumstances and ensure the 
reliability for using different compression algorithms. 

Without reset the protocol entity's state machine 
including, e.g., internal timers and counters have to be 

3 0 copied exactly "as is" in the source SRNC at the very 
moment when the handover occurs . This would increase 
much of complexity to UMTS which should be avoided as far 
as possible. The information from the source RNC to the 
target RNC has to be conveyed via at least two Iu 

3 5 interfaces and furthermore possibly via the interface 
between two SGSNs . This will increase overall delay 
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which might cause unpredictable problems especially with 
real time applications. Furthermore the transmission can 
be unreliable over any link and so in this case the 
probability of a copy failure grows. 
5 From the header compression point of view the reset 

brings also more reliability. That is because there have 
been developed header compression methods which are based 
on differential coding. This means that a compressed 
header can be decompressed only by knowing exactly the 

10 structure of the previously sent header. So there is an 
absolute correlation between sequential packets. If the 
header compression continued at the same state in the 
target RNS in a handover case it would require an exact 
copy of the compressor or decompressor entities. This 

15 will increase unreliability and delay as was described 
above. In the case of the use of differential header 
compression algorithms, one packet loss will usually 
generate additional packet loss. Thus the sending of the 
first packet from the target RNC has to succeed to hold 

2 0 the compressor synchronization. In radio circumstances 

where the bit error ratio may alternate randomly a 
correct reception is not always clear. The conclusion 
can be made that with long periods of time in such 
conditions where the bit error ratio varies much the 
25 behavior is irregular. So the likelihood for successful 
handover would diminish if state machines are copied to 
the target SRNC. If the reset is instead used for the 
compressor or decompressor then the first packets to the 
target are sent without compression so the risk that loss 

3 0 of synchronization occurs diminishes considerably. 

RLC reset in the UE is not always necessary but it 
is needed when there are remaining compressed headers in 
the RLC buffer which have been compressed with the 
algorithm of the source RNC and new PDCP parameters have 
3 5 been negotiated for a new header compression method. 

Then the buffered packet can't be decompressed in the 
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decompressor of the new method. 

These foregoing explanations show that there are 
good reasons to execute reset for RLC and PDCP entities. 

The second solution according to the present 
invention. is to use a change indicator such as a Change 
(C) bit as a flag to signal a desired or actual change in 
parameters. Fig. 6 shows the currently contemplated PDCP 
data PDU that is intended to be used to convey a payload 
unit containing a PDCP-SDU, header compression related 
control signaling or data that has been obtained from the 
PDCP-SDU after header compression. The PDCP-data-PDU 
parameters are defined using the PDU type bits 6-8 and 
the PID bits 1-5 of octet #1. The PID field value 
defines the header compression type used and the packet 
type. One compression algorithm may reserve a certain 
amount of values from the PID field value space for 
different packet types. When receiving a PDCP packet, 
the reverse operation is carried out in the header 
decompression, according to the PID field value. There 
is no fixed relationship between the PID field value and 
the used optimization/packet type, but PID field values 
are defined dynamically at the time of the PDCP parameter 
negotiation. According to one embodiment of the change 
indicator of the present invention, a C-bit might be 
added by defining a new PDU- type such as shown in Fig. 7. 

As can be seen, the number of bits available f or Jthe PID 
value has been shortened from five to four, and the extra 
bit has been designated for use as the C-bit. On the 
other hand, if the PID value is difficult to shorten, the 
C-bit could be added somewhere else, for instance, to 
octet #2. PDCP negotiation can be similar to XID 
negotiation in GPRS (or the actual negotiation can be 
carried out, e.g., via the control plane or by some other 
method). The inventive change indicator, e.g., in the 
form of a C-bit can -be a "flip-flop 1 type. Every time 
XID/PDCP parameters are renegotiated and take effect for 
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use, the C-bit changes its state CO' -> '1' or vice 
versa) . The C-bit remains the same until the next 
renegotiation. As an optional benefit, even if packets 
are out of sequence, the receiver can still handle a 
given packet correctly. When the receiver gets a packet 
with a changed C-bit, it "knows" that negotiation has 
taken place and uses the correct parameter values. But 
if in the next packet C-bit has changed again, the 
receiver knows that the packet is in the wrong order 
(sequence numbers not necessarily needed) and uses the 
old parameter values. There should of course be some 
fixed minimum time difference between two XID/PDCP 
negotiations, so that the receiver can know when 
parameters are actually changed or that a packet is only 

out of sequence . 

A detailed implementation of the invention is 
described below in connection with Figs. 8 and 9 for the 
case where unreliable XID/PDCP negotiation is used 
(unreliable negotiation means that retransmission of 
XID/PDCP messages shall be considered when using the C- 
bit method) : 

1. As shown in Fig. 8, the originator (either end; MS 
or network side - in UMTS: network side = RNC, in 
GPRS: network side = SGSN) starts XID/PDCP parameter 
negotiation by requesting XID/PDCP parameters, as 
indicated in a step 402. These XID/PDCP parameters 
are transferred to the peer entity. The originator 
starts a retransmission timer in a step 404. The 
timer determines the time when an XID/PDCP request 
is retransmitted. The originator will not start in 
new negotiation until a return is made after the 
routine of Fig. 8 concludes after step 424, for 
instance . 

2. The peer entity, i.e., the receiver responds as 
shown in Fig. 9, by receiving the request, as 
indicated in a step 502, negotiates parameters and 
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replies with negotiated parameters in a step 504 
back to the originator. The receiver starts a 
negotiation timer in a step 506. The timer 
determines the time when a new XID/PDCP negotiation 
5 is allowed by receiver. 

3 . The receiver can now start to use the new parameters 
for incoming packets (after sending XID/PDCP reply 
of step 5 04 .to- the originator) that come from an 
upper layer, e.g., in MS from the user to the ' PDCP 
10 layer and in RNC from the relay layer to the PDCP. 

The receiver changes {flips) a C-bit of the first 
XID/PDCP packet, as shown in a step 50 8, which used 
the new parameters. (The C-bit remains the same in 
all forthcoming packets until the next XID/PDCP 
15 negotiation, as indicated in a step 510.) 

4. For so long as the timer of step 404 of Fig. 8 is 
unexpired, as determined in a step 4 06, the 
originator checks for a response to the request for 
parameter negotiation in a step 408 and continues to 
20 use the old XID/PDCP parameter values for newly- 

received packets, as indicated in steps 410, 414 (as 
long as the C-bit is not flipped) until it receives 
an XID/PDCP negotiation response from the receiver. 
If it is determined in step 412 that the C-bit is 
25 flipped, the packet is discarded as per step 416. 

After receiving the response sent by the receiver in 
step 504 of Fig. 9, the originator of Fig. 8 can 
stop the timer (step 418) , and use the new XID/PDCP 
parameters. The originator changes (flips) the C- 
30 bit in the first outgoing XID/PDCP packet that goes 

to the receiver which used the new parameters, as 
indicated in steps 42 0, 422. Similarly, incoming 
packets with the C-bit flipped are assumed to be 
using the new parameters. If the C-bit is not 
35 flipped, then they are discarded, as shown in step 

424 . 
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Exception cases with possible extensions: 

If the originator receives a packet with a 
changed C-bit before it received the XID/PDCP reply 
5 (XID/PDCP reply may be delayed or lost) , it holds or 
discards the packet (s) until it receives an XID/PDCP 
reply, as suggested in steps 408-416 of Fig. 8, for 
instance. 

It should also be mentioned that if the 
10 retransmission timer started in step 404 is not elapsed 
and the originator has already received packet (s) with 
the changed C-bit, as indicated by a "yes" in step 412, 
all packets received with the "old" C-bit value are 
considered to be "out of sequence" . This packet is 
15 either discarded, as indicated in the step 416, or if 
possible, handled by the old XID/PDCP parameters. 

Similarly, if XID/PDCP negotiation is not done 
at all and the C-bit is changed, all packets received 
with a changed C-bit value can be considered to be 

2 0 invalid and thus discarded. 

If XID/PDCP reply from receiver is lost, the 
originator may retransmit the XID/PDCP request when the 
retransmission timer has elapsed (this is not a new 
XID/PDCP negotiation) . In this event, a retransmission 
25 count is increased in a step 426 and a determination is 
made in a step 42 8 if the maximum number of 
retransmissions has been reached or exceeded. If so, a 
fatal error is declared in a step 43 0, followed by a 
return. If not, the steps 4 02 et seg. are re-executed. 

3 0 Not shown in Fig. 8 are steps that may be carried 

out after it is determined in the step 406 that the timer 
has expired. If the timer started in step 404 is elapsed 
and the C-bit is changed, all packets received with "old" 
C-bit XID/PDCP parameter values can be considered to be 
3 5 invalid and thus discarded. Such steps could be carried 
out within the routine of Fig. 8 or in another routine. 

12 
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Referring back to Fig. 9, if the negotiation timer 
started in the step 506 has not yet expired, as 
determined in a step 512, a determination is made in a 
step 514 whether a retransmit request has been received. 

If so, a retransmit response is made in a step 516, and 
the negotiation timer is restarted in a step 518, after 
which the step 512 is re -executed. If it is determined 
in the step 514 that a retransmit request has not been 
received, a determination is made in a step 516 whether a 
new packet has been received. If not, the step 512 is 
executed again to find out if the negotiation timer has 
expired. If so, a step 518 is executed to determine if 
the C-bit is flipped in the newly-received packet. If 
so, the new parameters are used, as indicated in a step 
520. If not, the old parameters are used, as indicated 
in a step 522, and the step 516 is again executed. 

Referring back to the step 512, if it is determined 
that the negotiation timer has expired, it is determined 
in a step 524 whether any incoming packet has a flipped 
C-bit . If so, the new parameters are used, and otherwise 
it is discarded. A return is then made in a step 52 6. 

Referring now to Figs. 10 and 11, these provide for 
a detailed implementation for a case where actual 
XID/PDCP negotiation can be considered to be reliable. 
In this case, the lower layer (in UMTS case: RRC, Radio 
Resource Control) takes care of reliability, and thus the 
layer that uses the C-bit method doesn't need to take 
care of retransmissions, as in the steps shown in Figs. 8 
and 9. A much simpler procedure is therefore shown in 
Figs. 10 and 11. The RRC negotiates the parameters and 
then informs the PDCP, which then takes care of actions 
related to the C-bit, as shown in Figs. 10 and 11. 
Basically, Fig. 10 is the same as Fig. 8, except for the 
functions related to the retransmission timer. 
Similarly, Fig. 11 is similar to Fig. 9, except for the 
steps related to retransmissions which are not taken care 



13 



WO 01/47206 PCT/IBOO/01868 

of here, but rather by the lower layer (RRC in UMTS) . 

Referring now to Fig. 12, a system is shown for 
sending and receiving packets between an originator and a 
receiver in a mobile telecommunications system during 
negotiation of a parameter for use between the originator 
and the receiver. The originator includes means for 
sending a parameter negotiation request from the 
originator to the receiver, means for flipping a change 
indicator bit (C-bit) after receiving a negotiation 
response from the receiver, means for subsequently 
sending packets to the receiver with the flipped C-bit 
using new parameters, means for checking the C-bit of 
packets incoming from the receiver for using the new 
parameters for packets in which the C-bit has been 
flipped, and means for discarding incoming packets 
without the flipped C-bit. Also shown are means for 
receiving a negotiation response from a receiver, means 
for using old or new parameters as the case may be, a 
retransmission timer, a control, means for sending 
packets, means for receiving incoming packets, means for 
checking retransmission time, a memory and an antenna. 

Similarly, the receiver includes means for receiving 
a parameter negotiation request from the originator, 
means for sending a negotiated parameter response with 
new parameters to the originator, means for flipping an 
indicator bit, means for sending packets to the 
originator with the flipped C-bit, means for using 
old/new parameters for incoming packets from the 
originator with the C-bit flipped, a negotiation timer, 
means for discarding incoming packets, a control, a 
memory and an antenna. The originator and the receiver 
of Fig. 12 interact with each other, according to the 
descriptions disclosed above in connection with Figs. 8 & 
9 or 10 & 11. It will be evident to any person of skill 
in the art how to carry out the above-described 
methodology on the system of Fig. 12. 
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Although the invention has been shown and described 
with respect to a best mode embodiment thereof, it should 
be understood by those skilled in the art that the 
foregoing and various other changes, omissions and 
additions in the form and detail thereof may be made 
therein without departing from the spirit and scope of 
the invention. 
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1. Method of sending and receiving packets by an 
originator in a mobile telecommunications system during 

5 negotiation of a parameter for use between said 
originator and a receiver in said mobile 
telecommunications system, comprising the steps of 
sending a parameter negotiation request from said 
originator to said receiver, and after receiving a 

10 negotiation response from said receiver, modifying a 
change indicator, sending future packets using new 
parameters to said receiver with said modified change 
indicator using new parameters, checking the change 
indicator of packets incoming from said receiver for 

15 using said new parameters for packets in which said 
change indicator has been modified. 

2. The method of claim 1, further comprising the 
step of discarding said incoming packets if the change 

20 indicator is unmodified. 

3. The method of claim 1, further comprising the 
step of using old parameters for said incoming packets 
without a modified change indicator. 

25 

4. The method of claim 1, wherein while waiting 
for said negotiation response from said receiver during a 
timed period, checking for a modified change indicator of 
packets received from said receiver and discarding any 

30 such packets with said modified change indicator while 
using old parameters for such packets without said 
modified change indicator. 
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5. The method of claim 1, further comprising the 
steps of : 

starting a retransmission timer after said step 
of sending a parameter negotiation request, 

repeatedly checking said retransmission timer 
until expiration without receipt of said negotiation 
response, and in that event, 

resending said parameter negotiation request 
from said originator to said receiver. 



6. Method of receiving and sending packets by a 
receiver in a mobile telecommunications system during 
negotiation of a parameter for use between said 
originator and' said receiver, comprising the steps of: 

15 receiving a parameter negotiation request from 

said originator, 

sending a negotiated parameter response with 
new parameters to said originator, 

sending packets to the originator with new 
20 parameters and a modified change indicator, and 

using said new parameters for incoming packets 
from said originator with said change indicator modified. 

7. The method of claim 6, further comprising the 
25 steps of : 

starting a negotiation timer at the same time 
as sending said negotiated parameter response with new 
parameters to said originator, and after said timer 
expires , 

3 0 discarding incoming packets without a modified 

change indicator. 
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8. The method of claim 7, further comprising the 
step of : 

using old parameters for incoming packets 
without a modified change indicator and said new 
5 parameters for incoming packets with said modified change 
indicator until said negotiation timer expires. 

9. The method of claim 6, further comprising the 
steps of : 

10 starting a negotiation timer at the same time 

as sending said negotiated parameter response with new 
parameters to said originator, and after said timer 
expires , 

using old parameters for incoming packets 
15 without a modified change indicator and said new 

parameters for incoming packets with said modified change 
indicator until said negotiation timer expires. 

10. Method of sending and receiving packets between 

2 0 an originator and a receiver in a mobile 

telecommunications system during negotiation of a 
parameter for use between said originator and said 
receiver, comprising the steps of: 
by said originator: 
25 sending a parameter negotiation request from 

said originator to said receiver, and after receiving a 
negotiation response from said receiver, modifying a 
change indicator, sending future packets to said receiver 
with said modified change indicator using new parameters, 

3 0 checking the change indicator of packets incoming from 

said receiver for using said new parameters for packets 
in which said change indicator has been modified and 
otherwise discarding said incoming packets; 
by said receiver: 
35 receiving a parameter negotiation request from 

said originator, 
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sending a negotiated parameter response with 
new parameters to said originator, 

sending packets to the originator with the 
modified change indicator and using said new parameters, 
5 and 

using said new parameters for incoming packets 
from said originator with said change indicator modified. 

11. Apparatus for sending and receiving packets by 
10 an originator in a mobile telecommunications system 

during negotiation of a parameter for use between said 
originator and a receiver in said mobile 
telecommunications system, comprising: 

means for sending a parameter negotiation 
15 request from said originator to said receiver with a new 
parameter specified, 

means for modifying a change indicator after 
receiving a negotiation response from said receiver, 

means for sending subsequent packets to said 
20 receiver with said modified change indicator using the 
new parameter, and 

means for checking the modified change 
indicator of incoming packets from said receiver for 
using said new parameters for packets in which said 
25 change indicator has been modified. 

12. The - apparatus of claim 11, further comprising 
means for discarding said incoming packets if the change 
indicator is unmodified. 

30 

13. The apparatus of claim 11, further comprising 
means for using old parameters for said incoming packets 
without a modified change indicator. 

35 14. The apparatus of claim 11, further comprising: 

means for checking for a modified change 
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indicator in packets received from said receiver while 
waiting for said negotiation response from said receiver 
during a timed period, and 

means for discarding any such packets with said 
5 modified change indicator while using old parameters for 
such packets without said modified change indicator. 

15. The apparatus of claim 11, further comprising: 
means for starting a retransmission timer after 

10 said step of sending a parameter negotiation request, 

means for checking said retransmission timer 
until expiration without receipt of said negotiation 
response, and, 

means for resending said parameter negotiation 
15 request from said originator to said receiver in that 
event . 

16. Apparatus for receiving and sending packets by 
a receiver in a mobile telecommunications system during 

20 negotiation of a parameter for use between said 
originator and said receiver, comprising: 

means for receiving a parameter negotiation 
request from said originator, 

means for sending a negotiated parameter 
25 response with new parameters to said originator, 

means for sending packets to the originator 
with new parameters and a modified change indicator, and 

means for using said new parameters for 
incoming packets from said originator with said modified 
3 0 change indicator. 

17. The apparatus of claim 16, further comprising: 
means for starting a negotiation timer at the 

same time as sending said negotiated parameter response 
3 5 with new parameters to said originator, and 

means for discarding incoming packets without a 
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modified change indicator after said timer expires. 



18. The apparatus of claim 17, further comprising 
means for using old parameters for incoming packets 

5 without a modified change indicator and said new 

parameters for incoming packets with said modified change 
indicator until said negotiation timer expires. 

19. The apparatus of claim 16, further comprising: 
10 means for starting a negotiation timer at the 

same time as sending said negotiated parameter response 
with new parameters to said originator, and after said 
timer expires, 

means for using old parameters for incoming 
15 packets without a modified change indicator and said new 
parameters for incoming packets with said modified change 
indicator until said negotiation timer expires. 



BNSDOCID: <WO_____0147206A2J_> 



21 



WO 01/47206 PCT/IB00/01868 

20. System for sending and receiving packets 
between an originator and a receiver in a mobile 
telecommunications system during negotiation of a 
parameter for use between said originator and said 
5 receiver, comprising: 

in said originator: 

means for sending a parameter negotiation 
request from said originator to said receiver, 

means for modifying a change indicator after 
10 receiving a negotiation response from said receiver, 

means for sending future packets to said 
receiver with said modified change indicator using new 
parameters, 

means for checking the change indicator of 
15 packets incoming from said receiver for using said new 

parameters for packets in which said change indicator has 
been modified; and, 

in said receiver: 

means for receiving a parameter negotiation 
20 request from said originator, 

means for sending a negotiated parameter 
response with new parameters to said originator, 

means for sending packets to the originator 
with a modified change indicator and using said new 
2 5 parameters , and 

means for using said new parameters for 
incoming packets from said originator with said modified 
change indicator . 

30 21. The system of claim 20, further comprising, in 

said originator, means for discarding said incoming 
packets without said modified change indicator. 
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